User-Level Security : Service Credentials

In the absence of any information to indicate differently, the Windows credentials for the service are used, assuming that the binding requires mutual authentication because of transport security or message security. If you desire a different set of credentials for the service, you must specify them in the serviceCredentials element within the behaviors section. For example, the following segment from a configuration file tells the service to use the certificate with a subject name of UpdateKey in the local certificate store:

<behaviors>
  <serviceBehaviors>
    <behavior name="serviceBehavior" >
      <serviceCredentials>
        <serviceCertificate findValue="RPKey"
          storeLocation="LocalMachine" storeName="My"
          x509FindType="FindBySubjectName" />
      </serviceCredentials>
    </behavior>
  </serviceBehaviors>
</behaviors>

If you plan on using an alternative set of credentials, it is important to be aware of some of the potential ramifications. For example, in the preceding segment, a certificate is specified for the service’s credentials. If the client needs to encrypt the message sent to the service, the public key portion of this certificate must be available to the client. This can be provided either out of band (by providing the public key information to install on the client) or it can be negotiated with an initial handshake. The choice you make is specified in the negotiateServiceCredential attribute in the message element of the binding, as shown in bold in the following example:

<wsHttpBinding>
  <binding name="wsHttp">
    <security mode="Message">
      <message clientCredentialType="Certificate"
         negotiateServiceCredential="true" />
    </security>
  </binding>
</wsHttpBinding>

Again, as a caveat, the protocols used to negotiate are not interoperable in all situations. For Windows credentials, the SPNEGO protocol is used. For UserName, Certificate, or anonymous credentials, the TLSNEGO protocol is used. These protocols request the correct encryption token dynamically before any messages are exchanged.

Alternatively, when the automatic negotiation of service credentials is disabled, there are also some limitations. If Windows client credentials are to be used, a Kerberos domain must be available. This domain retrieves the encryption token. For other client credential types, the service credentials can be hard-coded, as shown in bold in the following segment:

<behavior name="Client">
  <clientCredentials supportInteractive="false">
    <clientCertificate storeLocation="CurrentUser"
       storeName="TrustedPeople" x509FindType="FindBySubjectName"
       findValue="UpdateKey"/>
    <serviceCertificate>
    <defaultCertificate storeLocation="CurrentUser"
       storeName="TrustedPeople x509FindType="FindBySubjectName"
       findValue="localhost"/>
    </serviceCertificate>
  </clientCredentials>
</behavior>

Alternatively, an encoded version of the public portion of the service’s certificate can be supplied in the definition of the endpoint. For example, the following segment from a configuration file is generated by the svcutil utility:

<client>
  <endpoint address="http://localhost:8000/UpdateService"
     binding="wsHttpBinding" contract="UpdateService"
     name="WSHttpBinding_UpdateService">
     <identity>
       <certificate encodedValue="AwAAAAEAAAAUAAAA...oVbTtOA=="/>
     </identity>
  </endpoint>
</client>